這篇開始，回到CASSANDRA/SCYLLA 一些分散式資料庫的系統處理介紹。

還記得Day4. 淺談分散式DB概念的簡介嗎？

想認識CASSANDRA/SCYLLA怎麼做到跨機器同步資料，怎麼追求不同節點資料的最終一致性，這些知識都無可厚非，我們必須認識它們。

首先，分佈在不同節點，每個在不同機器上的CASSANDRA/SCYLLA資料庫，可能遇到物理/系統層面的非預期意外。

好比機器的電源線被拔了，網路突然不通了，機器突然當機了等等，某個節點上的服務突然不能使用。

如此去想，馬上就浮出現幾個問題：

1. 什麼時候可以偵測到某個節點出問題？
2. 某個出問題的節點，是短暫的某個執行命令卡住/做太久，還是整台機器死翹翹。
3. 即使服務有通，那麼執行的動作怎麼知道是否正常，明明叫它寫入資料，實際上卻沒有寫進去之類的等等。

CASSANDRA/SCYLLA 利用gossip機制，去做節點和服務的偵測。

gossip直接翻譯起來叫『八卦』/『謠言』，比較常聽到通俗的講法，就是『病毒式傳播』。

亦即每個成員都可以是傳播者/主動發起者，並沒有一定是要某個核心成員主導才能作業。

P2P就是這樣的概念，這種機制並非CASSANDRA/SCYLLA專有，在分散式系統，是很常出現的機制，只差在實作細節的不同。

這種機制有什麼好處和壞處呢？

我們拿中心化/主從式的系統做比較，好處和壞處同樣很明顯。

好處：

1. 成員內誰都可以是發起者，散播者，所以速度很快，比起只有中心節點負責發起所有作業，速度無法相比，就跟病毒傳播的方式一樣。
2. 不用擔心中心節點卡住或者故障問題。
3. 擴充成員便利，基本上沒什麼侷限。

壞處：

1. 不公平現象，有的成員可能運氣好，身為熱門節點，大量的資料交換，有的成員運氣不好，幾乎乏人問津。
2. 承第一點，萬年邊緣人現象，成員數量龐大時，可能有成員，在第一次接收到資訊所花費的時間，久到難以想像。舉例一下，某個最新的消息，從第一個節點開始散播之後，用了總時間的5%，95%的成員就已經收到這個消息，但是有5%的成員，卻需要經過總時間的95%，才第一次拿到消息。

CASSANDRA/SCYLLA 在每個節點開始運作時，該節點就會有一個叫做gossiper的部分，專門處理針對其他節點狀態的偵測資訊。

gossiper會每秒隨機挑選叢集當中某一個節點，與之建立gossip session，每次這樣的gossip動作，會有三次訊息來回傳遞。

簡單來說就像tcp的handshake(三向交握)，send+recv+ack。

確認對方節點是否存活，若這個gossip動作失敗，該gossiper對於節點的維護列表，會在上頭記上一筆。

但是一次失敗，並不是馬上就判斷對方節點失效了。

而是有個進階的累積錯誤演算法，計算一個叫做Phi的數值，藉此判斷目標節點的狀況。

不過這已經是很底層的部分，我們並不需要特別了解實際的演算法運作，大概曉得概念就好。

以上關於gossip的介紹到這邊。